大家好！歡迎來到鐵人賽第十三天。

前兩天，我們已經陸續完成了兩個重要階段：Day 11 讓 FastAPI 成功將整理後的漏洞資料送進 n8n，Day 12 則串接了 LINE Bot，讓告警訊息能第一時間推播到手機裡。

目前的系統已經可以完美做到：
Wazuh ➔ FastAPI ➔ n8n ➔ LINE Bot ➔ 📱 管理人員收到告警

但是仔細想想，這樣的系統其實還是停留在「發現問題 ➔ 通知人員」的階段。在傳統的 IT 維運場景中，如果系統收到告警後，工程師還是得自己手動 SSH 登入伺服器、查詢套件、輸入指令修補，那整個流程依舊耗費大量人力，且容易錯失處理的黃金時間。

今天，我們要再往前跨出一步：除了讓系統「通知我有問題」，能不能讓它在符合特定條件的情況下，主動替我們執行安全維運工作？這就是今天要接觸的核心概念：SOAR（資安協調、自動化與回應）。

一、什麼是 SOAR？

SOAR 可以簡單理解為「讓資安事件的處理流程更加自動化」。
也就是把規則明確、步驟重複的工作交給系統執行。例如：
發現資安事件 ➔ 自動分析 ➔ 判斷是否符合條件 ➔ 執行指定處置 ➔ 回報執行結果

這也是我們選用 n8n 的最大價值。它不只是一個 Webhook 接收器，還能把不同服務串成一個完整的 Workflow。今天，我們要讓它具備「連線到測試主機並執行維運指令」的能力。

二、為 n8n 建立 SSH 連線與憑證

如果要讓 n8n 遠端操作 Linux 主機，最常見的方法就是使用 SSH。
在 n8n 畫布中點擊「＋」，搜尋並加入 SSH 節點。

加入之後，第一件事是建立連線鑰匙（SSH Credential）：

在 Authentication 選擇驗證方式。企業環境強烈建議使用 Private Key，而非將登入密碼明文交給自動化流程。

填入 Host（測試機 IP）、User（登入帳號）與對應的私鑰。

儲存 Credential。

(💡 實務小知識：今天的目的絕對不是讓系統收到任何漏洞告警就「無腦修補」。在真實企業環境中，自動修補涉及服務中斷與版本相容性風險。因此我們只會在自己的 Ubuntu 測試機上進行實驗。)

三、先驗證連線，再執行處置

很多初學者一拿到 SSH 節點，就會興奮地把 $json.body.package 塞進 apt upgrade 裡面。這在資安設計上是非常危險的！ 如果外部傳入的 Payload 被惡意竄改，等於是讓駭客透過我們的系統執行任意指令。

好習慣是：先做最簡單的連線測試。
在 Command 欄位先輸入 hostname 或 whoami。這不會修改系統，只要 n8n 順利回傳了 Ubuntu-Web-01 等字樣，就代表 n8n ➔ SSH ➔ Ubuntu 的連線已經成功打通。

四、核心安全設計：允許清單 (Allowlist)

我們不應該收到什麼就執行什麼，工作流必須具備「決策 (Decision)」的能力。

在 Webhook 與 SSH 節點之間，請加入一個 IF 節點 (或 Switch 節點) 來實作「允許清單」。假設我們目前只允許系統自動修補 curl 或 openssl 這兩個相對單純的套件：

• TRUE 分支 (符合允許清單)：走向 SSH 節點，執行 sudo apt-get install --only-upgrade {{ $json.body.package }} -y。
• ALSE 分支 (不在清單內)：走向 LINE Bot 節點，發送「未授權自動修補，請人工處理」的通知。

這樣一來，就算系統收到一筆異常資料，也絕對不會讓自動化流程暴衝，確保了維運操作的安全性。

五、把執行結果回傳到 LINE，完成閉環

既然目標是建立 SOAR，那麼「執行完之後發生什麼事」也很重要。我們要把 SSH 的執行結果再交給後面的 LINE 節點。

最後完成的工作流雛形會長這樣：

┌──→ (條件不符) ──→ LINE 通知 (請求人工介入)
                 │
Wazuh → FastAPI → n8n IF 節點
                 │
                 └──→ (條件符合) ──→ SSH 自動修補 ──→ LINE 通知 (回報處置成功)

現在，管理員收到的訊息就不只是單純的「發現漏洞」，而是能清楚掌握「系統是否執行了處置，以及處置的最終結果」。

下一步：漏洞的真實性？

今天我們成功建立了從 Detection（偵測）➔ Decision（決策）➔ Response（回應）的自動化雛形。

不過做到這裡，我反而開始思考一個更深層的問題：Wazuh 說有漏洞，就代表這台主機真的存在這個漏洞嗎？
資安系統往往充滿誤判（False Positives）。如果沒有進一步確認，我們就直接讓系統修改伺服器，反而可能引發維運災難。

比「如何自動修補」更重要的問題其實是：「如何在處置之前，確認漏洞到底是不是真的？」

接下來的鐵人賽，我們將正式進入全新領域：研究 CVE 漏洞情報、引入 RAG 架構與 AI 分析，讓系統在採取行動前，具備自我驗證與深度思考的能力！我們明天見！